One of the key strengths of a wireless mesh network is the ability to share information and components among nodes. In this exercise, you’ll see how a node with a temperature sensor can trigger a buzzer when a parameter is exceeded.
This exercise uses the SN171 setup used in the exercises Interacting with a Node via Portal and Using a Sensor to Influence Node Behavior. If you haven't completed those exercises, take a look at them to see how your LEDs and photo cell should be installed.
Adding a Buzzer to the SN171
We’ll use the connections in the upper right hand corner of the SN171 protoboard (GPIO 18, VCC, and GND) to attach the thermistor and the 150K pull-up resistor for this demonstration.
NOTE: You can differentiate the included resistors by color. The 300K Ohm resistor is tan in color, while the 150K Ohm resistor is blue. We’ll add the blue resistor for this demonstration.
To add a buzzer to the SN171:
Make sure that you still have the SN171 protoboard’s node (the one with “TemperatureAlarm2XX” in it) selected in the Node View pane.
Switch to the Node Info pane and find the “TemperatureAlarm2XX” specific section from the list of available functions. Click the soundAlarm() function to test the buzzer. You should hear a long beep from the buzzer. (If you do not hear the beep, confirm that you have the buzzer’s polarity correct in your installation.)
Sounding an Alarm
Now that we've got a buzzer attached to our protoboard, let's look at how to use it.
As you saw during the test, the soundAlarm() function triggers the buzzer. This means that any SNAPpy script running on the node can trigger an alarm by calling soundAlarm().
Since this node is ALSO a member of a SNAP network, any node within the mesh can sound an alarm just as easy. First, let's look at how we instruct every node to sound an alarm.
Using the multicast command
A multicast is essentially a command that tells every node in the mesh to do something. The syntax for the command looks like this:
mcastRpc(group, ttl, function, args…)
Group - Nodes can be configured to belong to "groups" within the mesh, and this parameter designates which group gets the message. For now, we'll use "1" which corresponds to everyone.
tti - ttl stands for "time to live" which sounds a little ominous out of context. What this is really saying is, "How far away from the original node should this message travel?" Each time a message is relayed from one node to another, it's called a "hop". ttl specifies how many "hops" the message should take before it's discarded.
function - This is the function that'll be invoked on the nodes. In this case, we're going to use soundAlarm().
args - If the function being invoked has any arguments that go with it, they'll go here. We'll look at this more in another exercise.
If we want to have every node within two hops to execute the soundTheAlarm function, the command would look like:
mcastRpc(1,2,"soundTheAlarm")
We can put this to work, but first we'll need another sensor. Check out the exercise Multicasting a Command for an exploration of this.